home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 15576 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  4.9 KB
  1. Path: news.salford.ac.uk!aber!not-for-mail
  2. From: pcg@aber.ac.uk (Piercarlo Grandi)
  3. Newsgroups: comp.object,comp.lang.eiffel,comp.lang.c++,comp.lang.beta,comp.lang.java,comp.lang.sather
  4. Subject: Re: What Should An Exception Handling Do? -- Clarification of rules
  5. Date: 05 Apr 1996 17:38:52 +0100
  6. Organization: Prifysgol Cymru, Aberystwyth
  7. Sender: pcg@osfb.aber.ac.uk
  8. Message-ID: <vwjvijer5gj.fsf@osfb.aber.ac.uk>
  9. References: <vwjg2ao6hqp.fsf@osfb.aber.ac.uk>
  10.     <1996Apr2.154722.29777@schbbs.mot.com>
  11. Reply-To: pcg@aber.ac.uk (Piercarlo Grandi)
  12. NNTP-Posting-Host: osfb.aber.ac.uk
  13. In-reply-to: shang@corp.mot.com's message of Tue, 2 Apr 1996 15:47:22 GMT
  14. X-Newsreader: Gnus v5.0.15
  15.  
  16. >>> On Tue, 2 Apr 1996 15:47:22 GMT, shang@corp.mot.com (David L. Shang)
  17. >>> said:
  18.  
  19. shang> In article <vwjg2ao6hqp.fsf@osfb.aber.ac.uk> pcg@aber.ac.uk
  20. shang> (Piercarlo Grandi) writes:
  21.  
  22. pcg> Therefore exception handling reduces to simply providing a mechanism by
  23. pcg> which the *author* of a code segment provides a mechanism by which the
  24. pcg> *user* of that code segment can specify additional cases, as for example
  25. pcg> in:
  26.  
  27. pcg> float sqrt(float n)
  28. pcg> {
  29. pcg>   if
  30. pcg>     n > 0 -> ...;
  31. pcg>     [] n == 0 -> return 0;
  32. pcg>     [] n < 0 -> return sqrt_negative(n);
  33. pcg>   fi
  34. pcg> }
  35.  
  36. pcg> where the only difficulty is that sqrt_negative must be dynamically
  37. pcg> scoped instead of statically scoped, for it must be redefinable by
  38. pcg> the *user* of the procedure.
  39.  
  40. pcg> This again means that termination is the only possible outcome for
  41. pcg> this case too.
  42.  
  43. shang> Termination? When you execute:
  44.  
  45. shang>     return sqrt_negative(n)
  46.  
  47. shang> first, you call "sqrt_negative" to get the result, then you do
  48. shang> return to terminate. It is not the case that you first terminate
  49. shang> then you call "sqrt_negative".shang> go back.
  50.  
  51. This is just a low level, mechanical view of
  52. exceptions/termination/resumption, as indeed demonstrated by your
  53. subsequent example, which is nothing but an assembler-like expansion of
  54. what I had written above:
  55.  
  56. shang> Once your terminate, you can never If I write code like:
  57.  
  58. shang>      float sqrt(float n)
  59. shang>      {
  60. shang>        if
  61. shang>           n > 0 -> ...;
  62. shang>        [] n == 0 -> return 0;
  63. shang>        [] n < 0 -> { n1= sqrt_negative(n); return n1; }
  64. shang>        fi
  65. shang>      }
  66.  
  67. shang> Is the program terminated
  68.  
  69. Why should one terminate the _program_? Exception handling's purpose is
  70. precisely not to terminate the program, but to allow it to continue,
  71. even if on a different path.
  72.  
  73. When we are talking of termination/continuation semantics, we are
  74. talking about the termination/continuation of the bit of code that had
  75. the problem, not that of the program (or even that of the containing
  76. scope, I would say).
  77.  
  78. shang> at the point of calling "sqrt_negative"?  This embedded exception
  79. shang> handler exactly provides a resumption semantics,
  80.  
  81. Not at all: for the 'if-fi' is not resumed/continued in any way.
  82.  
  83. Actually if you agree, as you logically must, that an "exception" is a
  84. misnomer for the case where a partial function is applied to a value
  85. outside its codomain, then talking about "exception handlers" and
  86. termination and continuation does not mean much: the only thing that
  87. matter is that the partial function is not continued, and that another
  88. bit of code is used.
  89.  
  90. The advocates of continuation semantics think that it makes sense
  91. because they imagine it is possible to make the exception handler wiggle
  92. things so that the current state of the computation is changed to one
  93. that *is* in codomain of the ``failing'' partial function; for example
  94. if on reading one gets EOF on the current volume, the exception handler
  95. can mount another volume, and on resumption the EOF is gone and
  96. everything is OK.
  97.  
  98. But I'd regard this a terrible use of "exception handling", for there is
  99. no need to use the machinery of dynamic binding in this case, because
  100. what happens on EOF is not something that cannot be designed in at the
  101. time the rest of the code is written; in fact essentially all the uses
  102. of continuation sematics amount to using exception handling instead of a
  103. 'case' or an 'if' with more branches.
  104.  
  105. shang> which, according to your previous analysis, is the only case that
  106. shang> exception handling makes any sense(?).
  107.  
  108. Perhaps we are using "termination" in a different sense: to me in a
  109. semantic sense, where the current computation simply cannot progress
  110. because it is a partial function applied to a value outside its
  111. codomain. If a partial function is applied outside its codomain, then it
  112. simply *cannot* be continued/resumed/...
  113.  
  114. You are instead perhaps thinking of non-local control transfers, as in:
  115. termination semantics for exceptions *necessarily* involve a non local
  116. control transfer.
  117.  
  118. To me the issue of exception handling and non local control transfers
  119. are totally unrelated and independent; not necessarily an exception
  120. handler shall 'longjmp'/'throw'/... outside the current function. What
  121. in any case *must* happen is that the current computation is not
  122. continued, for it cannot continue.
  123.